Einheit 3 — Workflows in Abschnitte teilen
Was du nach dieser Einheit weißt: Du verstehst was Sinnabschnitte sind, wann ein Workflow aufgeteilt werden sollte und wie Workflows über Source/Receiver miteinander kommunizieren.
Das Problem mit dem Monolith
Ein Workflow der alles in einer einzigen Kette macht — E-Mail empfangen, Anhang lesen, Daten extrahieren, im ERP nachschlagen, Auftrag anlegen, Bestätigung senden — funktioniert. Aber er hat Nachteile:
- Schwer zu testen — du musst immer den gesamten Prozess durchlaufen, auch wenn du nur den ERP-Teil ändern willst
- Schwer zu debuggen — wenn etwas schiefgeht, musst du den gesamten Workflow durchforsten
- Nicht wiederverwendbar — der ERP-Teil könnte auch in einem anderen Workflow nützlich sein, ist aber fest verdrahtet
- Fehleranfällig — ein Fehler in einem Teil bringt alles zum Stillstand
📸 Screenshot: [Platzhalter — Workflow-Designer: Ein langer, monolithischer Workflow mit 15+ Agents in einer einzigen Kette]
Was ist ein Sinnabschnitt?
Ein Sinnabschnitt ist ein abgeschlossener, wiederverwendbarer Teil eines Prozesses mit klar definierten Ein- und Ausgaben.
Die Frage die dir hilft Sinnabschnitte zu erkennen:
„Würde ich diesen Teil auch in einem anderen Prozess brauchen?"
Wenn ja → eigener Workflow.
Beispiel: Eingangsrechnungsverarbeitung
Der Gesamtprozess:
- E-Mail mit Rechnung empfangen
- PDF-Anhang extrahieren
- Rechnungsdaten aus PDF lesen (KI-Extraktion)
- Lieferant im ERP suchen
- Bestellung im ERP suchen und abgleichen
- Rechnung im ERP buchen
- PDF im DMS ablegen
- Bestätigung an Absender senden
Sinnvolle Abschnitte:
| Abschnitt | Agents | Ein-/Ausgabe |
|---|---|---|
| E-Mail & Anhang | Incoming Mail → JSON Split → Filter | Eingang: E-Mail. Ausgang: PDF-Datei |
| Datenextraktion | Read File → Generative AI → SQL Persist | Eingang: PDF. Ausgang: strukturierte Rechnungsdaten |
| ERP-Abgleich & Buchung | Post Agent (Suche) → Switch → Post Agent (Buchung) | Eingang: Rechnungsdaten. Ausgang: Buchungsstatus |
| DMS-Ablage | Post Agent (DMS Upload) | Eingang: PDF + Metadaten. Ausgang: DMS-Referenz |
| Bestätigung | Mail Agent | Eingang: Status. Ausgang: E-Mail |
📸 Screenshot: [Platzhalter — Workflow-Designer: Derselbe Prozess aufgeteilt in fünf separate Workflows, verbunden über Source/Receiver]
📹 Video: [Platzhalter — Screencast: Einen monolithischen Workflow Schritt für Schritt in Sinnabschnitte aufteilen]
Wie Workflows miteinander kommunizieren: Source und Receiver
Wenn ein Prozess auf mehrere Workflows aufgeteilt ist, müssen diese miteinander sprechen. In 42°OS geht das über Source und Receiver:
- Receiver Agent — steht am Anfang eines Workflows und wartet auf eine Nachricht von einem anderen Workflow
- Source Agent — steht am Ende (oder an einer beliebigen Stelle) eines Workflows und sendet eine Nachricht an einen anderen Workflow
Workflow A: Incoming Mail → ... → Source Agent ──────►
Workflow B: Receiver Agent → ... → Source Agent ──────►
Workflow C: Receiver Agent → ...
Die Nachricht die der Source Agent sendet, ist die Eingabe für den Receiver Agent. Die Struktur dieser Nachricht ist der Vertrag zwischen den beiden Workflows — sie definiert welche Daten übergeben werden.
📸 Screenshot: [Platzhalter — Source Agent Konfiguration: Ziel-Workflow auswählen und Nachricht definieren]
📸 Screenshot: [Platzhalter — Receiver Agent: Eingehende Nachricht im Run Inspector sichtbar]
Vorteile der Modularisierung
| Vorteil | Erklärung |
|---|---|
| Isoliert testbar | Jeden Abschnitt einzeln starten und prüfen, ohne den Rest auszuführen |
| Wiederverwendbar | Der DMS-Ablage-Workflow kann von jedem Prozess genutzt werden, nicht nur von der Rechnungsverarbeitung |
| Fehlerisolierung | Wenn die DMS-Ablage fehlschlägt, hat die ERP-Buchung trotzdem funktioniert |
| Übersichtlicher | Jeder Workflow passt auf einen Bildschirm und hat einen klaren Zweck |
| Parallelisierbar | Unabhängige Abschnitte können gleichzeitig laufen |
| Einfacher zu übergeben | Ein Kollege muss nicht den gesamten Prozess verstehen um einen Teil zu warten |
Wann aufteilen, wann nicht?
Nicht jeder Workflow muss aufgeteilt werden. Die Faustregeln:
Aufteilen wenn:
- Der Workflow hat mehr als ~8–10 Agents
- Ein Teil des Workflows könnte auch in einem anderen Prozess nützlich sein
- Du willst einen Teil isoliert testen können
- Verschiedene Personen sind für verschiedene Teile verantwortlich
Nicht aufteilen wenn:
- Der Workflow hat 3–5 Agents und tut genau eine Sache
- Die Abschnitte sind so eng verknüpft, dass eine Trennung die Komplexität erhöht statt verringert
- Der Workflow ist ein Einmal-Job oder Prototyp
Eine detaillierte Referenz zu Sinnabschnitten und Source/Receiver findest du in der Dokumentation unter Workflows in Abschnitte aufteilen.